The present invention is generally directed to device redirection in a virtual desktop infrastructure (VDI) environment. Device redirection generally refers to making a device that is connected to a client terminal accessible within a virtual desktop as if the device had been physically connected to the virtual desktop. In other words, when device redirection is implemented, a user can connect a device to his or her client terminal and the device will function as if it had been connected to the server.
FIGS. 1 and 2 and the following description will provide a general overview of how device redirection can be implemented in accordance with some embodiments of the present invention. In FIG. 1, a computing system 100 is depicted as including a number of client terminals 102a-102n (referenced generally herein as client(s) 102) in communication with a server 104 via a network 106. Server 104 can be configured to support a remote session (e.g., a remote desktop session) wherein a user at a client terminal 102 can remotely access applications and data at the server 104 from the client terminal 102. Such a connection may be established using any of several well-known techniques such as the Remote Desktop Protocol (RDP) and the Citrix® Independent Computing Architecture (ICA).
Client terminal 102 may represent a computer, a mobile phone (e.g., smart phone), a laptop computer, a thin client terminal, a personal digital assistant (PDA), a portable computing terminal, or a suitable terminal or device with a processor. Server 104 may represent a computer, a laptop computer, a computing terminal, a virtual machine (e.g., VMware® Virtual Machine), a desktop session (e.g., Microsoft Terminal Server), a published application (e.g., Microsoft Terminal Server) or a suitable terminal with a processor.
Client terminal 102 may initiate a remote session with server 104 by sending a request for remote access and credentials (e.g., login name and password) to server 104. If server 104 accepts the credentials from client terminal 102, then server 104 may establish a remote session, which allows a user at client terminal 102 to access applications and data at server 104. During the remote session, server 104 sends display data to client terminal 102 over network 106, which may include display data of a desktop and/or one or more applications running on server 104. The desktop may include, for example, icons corresponding to different applications that can be launched on server 104. The display data allows client terminal 102 to locally display the desktop and/or applications running on server 104.
During the remote session, client terminal 102 may send user commands (e.g., inputted via a mouse or keyboard at client terminal 102) to server 104 over network 106. Server 104 may process the user commands from client terminal 102 similar to user commands received from an input device that is local to server 104. For example, if the user commands include mouse movements, then server 104 may move a pointer on the desktop running on server 104 accordingly. When the display data of the desktop and/or application changes in response to the user commands, server 104 sends the updated display data to client terminal 102. Client terminal 102 locally displays the updated display data so that the user at client terminal 102 can view changes at server 104 in response to the user commands. Together, these aspects allow the user at client terminal 102 to locally view and input commands to the desktop and/or application that is running remotely on server 104. From the perspective of the client side, the desktop running on server 104 may represent a virtual desktop environment.
Windows I/O uses a layered architecture where device drivers are on a device stack. In a basic model, the top of the stack is the file system. Next is the volume manager, followed by the disk driver. At the bottom of the device stack are the port and miniport drivers. When an I/O request reaches the file system, it takes the block number of the file and translates it to an offset in the volume. The volume manager then translates the volume offset to a block number on the disk and passes the request to the disk driver. When the request reaches the disk driver it will create a Command Descriptor Block (CDB) that will be sent to the SCSI device. The disk driver imbeds the CDB into a structure called the SCSI_REQUEST_BLOCK (SRB). This SRB is sent to the port driver as part of the I/O request packet (IRP).
The port driver does most of the request processing including providing timing services for requests, enforcing queue depth (making sure that a device does not get more requests that it can handle), and building scatter gather arrays for data buffers. The port driver interfaces with a driver called the miniport. The miniport driver is designed by the hardware manufacturer to work with a specific adapter and is responsible for taking requests from the port driver and sending them to the target logical unit number (LUN). The port driver calls the HwStorStartIo( ) function to send requests to the miniport, and the miniport will send the requests to the LUN. When the request is complete, the miniport will call StorPortNotification( ) with the NotificationType parameter value set to RequestComplete, along with a pointer to the completed SRB.
FIG. 2 is a block diagram of a virtual device infrastructure (VDI) environment 200 which can implement this type of functionality when a mass storage device is redirected from a client terminal 102 to a server 104 over a remote session. As shown, while client terminal 102 has established a remote session with server 104, a mass storage device 240 is connected to client terminal 102. In accordance with embodiments of the present invention, client terminal 102 can be configured to redirect device 240 over the remote session so that the device is accessible on server 104. Proxy 210 on client terminal 102 and agent 250 on server 104 can be configured to establish and maintain the remote session to enable this redirection.
FIG. 2 provides a general overview of the primary components that can be employed to redirect mass storage device 240 at the disk level. This technique can be referred to as disk level redirection and is distinguished from general USB redirection in that the redirection occurs at the disk level rather than at the USB device level. In particular, client terminal 102 can include a disk driver stack 220 that includes a disk driver 220a, a USB storage driver 220b, and a USB hub driver 220c. As is known in the art, USB storage driver 220b and USB hub driver 220c can implement the USB protocol to enable communication with device 240 as a USB mass storage device. Disk driver 220a, which in some embodiments may be an instance of the disk.sys process, can function to service read/write requests and to abstract the underlying USB storage and hub drivers 220b, 220c. 
When mass storage device 240 is connected to client terminal 102, disk driver 220a may be configured to report the presence of device 240 to proxy 210 and to provide the device information (e.g., device descriptor) to proxy 210. Proxy 210 may be configured to report the presence of device 240, along with the device information, to agent 250 of server 104 over network 106. Thus, disk driver 220 redirects device 240 to server 104 via proxy 210.
Agent 250 may be configured to receive the report from proxy 210 that device 240 is connected to client terminal 102 and the device information. Agent 250 may further be configured to associate with the report from proxy 210 one or more identifiers for client terminal 102 and/or for a user session through which client terminal 102 is connected to server 104, such as a session number or a session locally unique identifier (LUID). Agent 250 can provide notification of device 240, along with the device information, to virtual disk enumerator 260. Virtual disk enumerator 260 may be configured to create and store in memory a record corresponding to device 240, the record including at least part of the device information and session identifiers received from agent 250. Virtual disk enumerator 260 may be configured to report to operating system 170 of server 104 that device 240 is connected and to provide the device information to the operating system. This allows the operating system of server 104 to recognize the presence of device 240 even though device 240 is connected to client terminal 102.
Based on the device information, operating system 170 may load a corresponding disk driver 282, which may be another instance of the disk.sys process, which may sit below a file system stack 280 to receive and convert file system requests to disk requests (e.g., by creating a CDB and embedding it in an SRB) and to pass these disk requests (e.g., IRPs and associated SRBs) to virtual disk enumerator 260 at the bottom of the device stack. It is noted that a volume manager is not shown in this figure for simplicity. Virtual disk enumerator 260 functions to virtualize mass storage device 240 on server 104 (as represented by virtual mass storage device 290). This virtualization is accomplished by routing the disk requests to agent 250 which will forward them over the remote session to proxy 210, down through disk driver stack 220, and to mass storage device 240 where they can be fulfilled. Corresponding responses can then be routed in a reverse direction towards virtual disk enumerator 260 and up through disk driver 282, file system stack 280, operating system 170, and ultimately to an application 270 that originated the request.
It is to be understood that an IRP itself is not transferred between proxy 210 and agent 250 (since much of the IRP is server-specific (e.g., pointers) and would therefore be meaningless on the client). Instead, sufficient content of the IRP is transferred from agent 250 to proxy 210 to allow proxy 210 to recreate (or to cause to be recreated) an equivalent IRP on the client side. A similar process is employed when proxy 210 returns results of handling an IRP. However, to simplify the description, this specification may refer to an IRP being sent by agent 250 to proxy 210. Also, in this specification, a SCSI command may be referred to as being sent to proxy 210. It is to be understood that a SCSI command would be sent to proxy 210 as part of the content of the IRP.
Oftentimes an older and/or simplified operating system may be employed on client terminal 102. In such cases, client terminal 102's operating system may not support all of the disk level commands that server 104's operating system supports. In a current example, server 104 may run Windows 8.1, Windows Server 2012 R2, or a later version that supports SCSI specification SPC-4 while client terminal 102 may run Windows Embedded 8 Standard, Windows 8, an earlier Windows version, or another operating system that only supports SCSI specification SPC-3 or lower. Also, many newer mass storage devices support SCSI specification SPC-4.
In scenarios where disk level redirection is implemented between a server and a client terminal having an operating system that does not support the same capabilities as the server's operating system, various issues arise due to the fact that file system stack 280 is implemented on server 104 while disk driver stack 220 is implemented on client terminal 102. For example, SCSI specification SPC-4 defines UNMAP/TRIM commands that allow the operating system to inform the storage device of which blocks of data are no longer considered in use and can therefore be wiped internally. These commands are especially important for flash-based disk devices and SSDs because they allow them to perform garbage collection efficiently.
If client terminal 102's operating system does not support SCSI specification SPC-4, the VDI may be configured to initialize mass storage device 290 on server 104 to use an older SCSI protocol version (e.g., SCSI specification SPC-3) even if mass storage device 240 and server 104's operating system support SCSI specification SPC-4. This is because disk driver stack 220 and particularly disk driver 220a (which will be limited by client 102's operating system) would not be able to support all of the commands of SCSI specification SPC-4. Alternatively, if mass storage device 290 is initialized to use the latest SCSI protocol version, operating system 170 will be able to send unsupported commands towards mass storage device 240 but disk driver 220a will reject these commands as unsupported. As a result, even though mass storage device 240 may be capable of handling the UNMAP/TRIM commands (or any other SCSI commands that are not supported by the client terminal's operating system), operating system 170 will not be able to send these commands to mass storage device 240. The end result is that mass storage device 240 will be unable to efficiently perform garbage collection leading to lower IOPs, higher write amplification, and a shortened disk life. In short, the client terminal's operating system oftentimes limits the performance of a redirected mass storage device.